feat(devops): add Husky pre-commit hooks for linting and type checkin… - #676

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

# Run in a disposable worktree with representative staged files.
npx lint-staged --debug 2>&1 | tee /tmp/lint-staged-debug.log
grep -E 'tsc --noEmit|cargo clippy' /tmp/lint-staged-debug.log

Repository: ritik4ever/stellar-goal-vault

Length of output: 159

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

echo "package.json:"
if [ -f package.json ]; then
  cat -n package.json | sed -n '1,100p'
else
  echo "package.json not found"
fi

echo
echo "lint-staged config references:"
grep -RIn '"lint-staged"|"lintStaged"|lint-staged|lintStaged' package.json pnpm-lock.yaml package-lock.json yarn.lock 2>/dev/null | sed -n '1,160p' || true

echo
echo "TypeScript config files:"
fd -a 'tsconfig.*json$|tsconfig' . | sed 's#^\./##' | sort | head -80

echo
echo "Rust files:"
git ls-files | grep -E '(^|/)Cargo\.toml$|\.rs$' | head -100

Repository: ritik4ever/stellar-goal-vault

Length of output: 2751

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

python3 - <<'PY'
# Deterministic model of lint-staged string task command:
# each matched string command is appended with the list of filenames.
commands = [
    "cd backend && tsc --noEmit",
    "cd frontend && tsc --noEmit",
    "cd contracts && cargo clippy -- -D warnings",
]
files = ["backend/src/foo.ts", "frontend/src/bar.tsx", "contracts/src/lib.rs"]

for cmd in commands:
    full = f"{cmd} { ' '.join(files) }"
    print(full)
PY

echo
echo "TypeScript configuration snippets:"
for f in backend/tsconfig.json frontend/tsconfig.json tsconfig.json frontend/tsconfig.node.json frontend/tsconfig.test.json backend/tsconfig.eslint.json; do
  if [ -f "$f" ]; then
    echo "--- $f"
    python3 - <<PY "$f"
import json, sys
p=sys.argv[1]
try:
    data=json.load(open(p))
except Exception as e:
    print(f"error: {e}")
    raise
if isinstance(data, dict):
    for k in ["compilerOptions","extends","include","exclude","references"]:
        if k in data:
            print(k, "=>", data[k])
else:
    print(data)
PY
  fi
done

echo
echo "lockfile lint-staged version:"
for f in package-lock.json pnpm-lock.yaml yarn.lock; do
  [ -f "$f" ] && { echo "--- $f"; grep -n "lint-staged" "$f" | sed -n '1,80p'; }
done

Repository: ritik4ever/stellar-goal-vault

Length of output: 1947

🌐 Web query:

lint-staged string tasks append staged file names lint-staged documentation

💡 Result:

By default, lint-staged automatically appends the list of matched staged files (passed as absolute paths) to the end of your configured command string [1][2][3]. For example, if you configure a task like this: "*.js": "prettier --write" And you have staged files named file-1.js and file-2.js, lint-staged will execute the following command: prettier --write /absolute/path/to/file-1.js /absolute/path/to/file-2.js [1][3][4] Key points to remember: 1. Automatic Appending: You do not need to specify where the file names go in a standard string command; lint-staged handles this for you [1][4]. If you include a path (e.g., "prettier --write."), lint-staged will append the staged files after that path, which may cause unexpected behavior [4]. 2. Function Syntax: When using the advanced JavaScript function syntax in your configuration, lint-staged does not automatically append the file names [1][5]. In these cases, you are responsible for manually including the staged files in your command string or array by using the argument provided to the function [1][3]. 3. Command Length: Because lint-staged appends these files as arguments, very long lists of files might exceed system limits [5]. lint-staged attempts to mitigate this by automatically splitting the list of files into chunks and running the command multiple times [5]. You can control this behavior with the --max-arg-length option if necessary [5].

Citations:

• 1: https://github.com/lint-staged/lint-staged/blob/main/README.md
• 2: https://github.com/okonet/lint-staged/
• 3: https://github.com/lint-staged/lint-staged
• 4: https://stackoverflow.com/questions/64429228/lint-staged-added-path-to-command
• 5: https://registry.npmjs.org/lint-staged

🌐 Web query:

"project" "file names" TypeScript tsc command line compiler rejects project mode filenames

💡 Result:

The TypeScript compiler (tsc) does not have a hard-coded prohibition against specific project filenames in "project mode" (invoked via --project or --build), but it does have specific behavioral requirements and limitations that can cause errors or unexpected rejection of certain files or paths [1][2][3][4]. Common reasons for issues often mistaken for "rejection" include: 1. Filename Parsing and Path Issues: When using tsc --project, if the path to your project contains spaces, the compiler may incorrectly split the path and attempt to interpret the latter part of the path as a separate source file, triggering error TS5042 (option 'project' cannot be mixed with source files) [1]. 2. Extension and Directory Resolution: - Files ending in.jsonc may be incorrectly treated as directories by certain build commands, leading to errors where tsc attempts to append /tsconfig.json to the path [3]. - If you provide a custom configuration filename that does not end in.json or.jsonc, or if the compiler is configured to look for specific naming conventions, it may fail to locate the project file correctly [3]. 3. File Naming Collisions: The TypeScript Language Server can fail to respect project configuration if source files in the project share the same name but differ only by extension (e.g., index.ts and index.tsx residing in the same directory) [2]. 4. Build Mode vs. Project Mode: Using --project (or -p) is fundamentally different from passing a list of files [1]. Mixing these modes—for example, passing a project file and additional source files on the same command line—is not supported and will be rejected [1]. Similarly, --build (tsc -b) has specific requirements for project configuration [5][4]. To avoid these issues: - Ensure project paths and filenames contain no spaces [1]. - Use consistent, standard extensions (.json or.jsonc) for your configuration files [3]. - Avoid mixing --project or --build modes with explicit source file lists on the command line [1]. - Ensure that source files within the project have unique names if possible, particularly when dealing with.ts and.tsx variants in the same scope [2].

Citations:

• 1: https://stackoverflow.com/questions/35813033/typescript-ts5042build-option-project-cannot-be-mixed-with-source-files-on-a
• 2: The TS Language Server will fail to use the project config when there is a file with both the .ts and .tsx extensions microsoft/TypeScript#57360
• 3: tsc --build and tsconfig project references treat paths ending in .jsonc as directories microsoft/TypeScript#60261
• 4: https://stackoverflow.com/questions/70703085/tsc-build-specify-tsconfig-json
• 5: https://www.typescriptlang.org/docs/handbook/project-references

🌐 Web query:

Cargo CLI -- separator unknown option after separator passed to subcommand

💡 Result:

The double-dash separator (--) in the Cargo CLI is used to distinguish between arguments intended for Cargo itself and arguments intended for the underlying process or tool being invoked (such as a compiled binary, a test harness, or the compiler) [1][2][3]. If you receive an "unknown option" error after the -- separator, it typically means one of the following: 1. Misplaced Arguments: You may be placing arguments intended for Cargo after the -- separator. Arguments placed after -- are passed directly to the sub-process [2][3]. If those arguments contain flags that look like Cargo options (e.g., --verbose), Cargo will not parse them, but the receiving tool might not understand them either, or the CLI parser may still flag them if they are improperly formatted [1][4]. 2. Tool-Specific Argument Parsing: Many tools invoked by Cargo (like test runners or benchmarks) have their own internal argument parsers [4]. If you pass an option that the target tool does not recognize, the error message may originate from that tool rather than Cargo [4]. For example, when running cargo bench or cargo test, arguments after the -- are passed to the test/benchmark harness [4]. Providing an invalid flag to that harness will result in an "unknown option" error [4]. 3. Correct Usage: Ensure that all flags intended for Cargo (such as -p, --release, or --bin) are placed before the -- separator [1][2]. Only pass arguments intended for the final executable or compiler after the -- [2][3]. Example: If you want to run a binary with the flag -r: - Correct: cargo run -- -r [1] - Incorrect: cargo run -r -- (where -r is for the binary) [1] If you believe the option is valid and should be supported by Cargo, ensure it is not a typo or an unstable flag that requires -Z [5][6]. You can verify the valid arguments for a command by running cargo <command> --help [5][7].

Citations:

• 1: Cargo not passing arguments to binary rust-lang/cargo#1855
• 2: https://doc.rust-lang.org/cargo/commands/cargo-run.html
• 3: https://doc.rust-lang.org/stable/cargo/commands/cargo-rustc.html
• 4: bench does not pass dash-prefixed arguments to binary rust-lang/cargo#10228
• 5: Display help menu if user provides an unknow option rust-lang/cargo#7122
• 6: https://dev-doc.rust-lang.org/nightly/cargo/commands/cargo.html
• 7: https://doc.rust-lang.org/cargo/commands/cargo-help.html